Processing network address identifiers

ABSTRACT

The invention provides a method, data processing system and software for generating address identifiers for use in a communications network. The method comprises the step of processing a first address identifier constructed in accordance with a first communications protocol; and the step of constructing a second address identifier, from said first identifier, in accordance with a second communications protocol. The first communications protocol may be protocol Simple Mail Transfer Protocol (SMTP) and the second communications Session Initiation Protocol (SIP). The invention enables messages to be sent to a SIP URL derived from an SMTP email URL. In the event that the SIP URL is invalid, or unregistered the SIP message is diverted from a SIP defined destination URL address identifier to a corresponding SMTP defined destination URL address identifier for the same user or end system. In this way users may send SIP messages to SMTP address identifiers using the SMTP network protocol and infrastructure ( 416 ) and SMTP messages to SIP address identifiers using the SIP network protocol and infrastructure ( 408, 410, 412 ).

[0001] This invention relates to a method of operating a communicationsnetwork.

[0002] The Session Initiation Protocol (SIP) is an application-layercontrol protocol for creating, modifying and terminating sessions havingone or more participants. These sessions include Internet multimediaconferences, Internet telephone calls and multimedia distribution.Members in a session can communicate via multicast or via a mesh ofunicast relations, or a combination of these. SIP supports sessiondescriptions that allow participants to agree on a set of compatiblemedia types. It also supports user mobility by proxying and redirectingrequests to the user's current location. SIP is not tied to anyparticular conference control protocol. There is widespread interest inthe protocol, especially for telephony-related applications. SIP wasproposed by the Internet Engineering Task Force (IETF) group and is nowa proposed standard published as RFC 2543.

[0003] The entities used in SIP are user agents, proxy servers, redirectservers and location servers. A SIP user agent is an end-system thatallows a user to participate in a session. A SIP user agent containsboth a user agent client and a user agent server. A user agent client isused to initiate a session and a user agent server is used to respond torequest from a user agent client. A user is addressed using anemail-like address identifier “user@host”, where “user” is a user nameor phone number and “host” is a domain name or numerical InternetProtocol (IP) address. SIP defines a number of request types, inparticular INVITE, ACK, BYE, OPTIONS, CANCEL, and REGISTER. Responses toSIP messages indicate success or failure, distinguished by status codes,1xx (100 to 199) for progress updates, 2xx for success, 3xx forredirection, and higher numbers for failure. Each new SIP transactionhas a unique call identifier (call ID), which identifies the session. Ifthe session needs to be modified, e.g. for adding another media, thesame call identifier is used as in the initial request, in order toindicate that this is a modification of an existing session.

[0004] The SIP user agent has two basic functions: listening forincoming SIP messages, and sending SIP messages upon user actions orincoming messages. The SIP user agent typically also starts appropriateapplications according to the session that has been established. A SIPproxy server can relay SIP messages—it is possible to use a domain nameto find a SIP proxy server, for example using the Domain Name System(DNS), rather than knowing the IP address or name of the host. A SIPproxy can thereby also be used to hide the location of the user. Aredirect server returns the location of the host rather than relayingthe SIP message. Both redirect and proxy servers accept registrationsfrom users, in which the current location of the user is given. Theuser's location can be stored at a dedicated location server.

[0005] SIP is typically implemented by transmitting Internet Protocol(IP) packets.

[0006] SIP is independent of the packet layer and only requires anunreliable datagram service, as it provides its own reliabilitymechanism. While SIP typically is used over UDP or TCP, it could be usedover frame relay, ATM AAL5 or X.25.

[0007] SIP is a text based protocol and is based to a certain extent (interms of syntax) on the HTTP protocol. A typical message consists of asingle request line, a number of header lines and a message body.

[0008] The request line indicates the type of the messages, the messagedestination and the SIP version it complies with. The following is atypical example:

[0009] INVITE sip:Richard@bt.com SIP/2.0

[0010] A header line contains the name of the header type, followed by asemicolon and the contents as these are defined for the specific header.Consequently, each header type is used for a specific purpose (either toindicate some parameters or to issue a request). The following aretypical examples:

[0011] From: sip:Richard@bt.com

[0012] To: sip:Steve@bt.com

[0013] Subject: Official meeting

[0014] The message body may be of any content, although it usually hascontents formatted in accordance with the Session Description Protocol(SDP).

[0015] SIP URL address identifiers such as sip:Richard@bt.com arerequired for the exchange of SIP messages in a similar way that e-mailURL address identifiers are required for the exchange of electronicmail.

[0016] By using an e-mail type address it is possible to deliver a SIPmessage to a SIP server that knows the location of the user or useragent server the message is intended for. The IP address of the SIPserver having authority for the callee's address can be readilydetermined by DNS. The above referenced proposed standard, RFC 2543,encourages implementers of SIP services to name SIP servers by appendingthe string ‘sip.’ to their domain name. It is further suggested that animplementation might derive an address for use in SIP communicationsfrom the intended recipient's e-mail address. The proposed method ofderivation is to add the prefix ‘sip.’ to the host part of the intendedrecipient's e-mail address (e-mail addresses normally being of the form‘user@host’).

[0017] According to an aspect of the present invention there is provideda method of operating a network to provide communications in accordancewith a first communications protocol, said method comprising:

[0018] receiving a base address identifier convertible by a firstdirectory server associated with said network to an address for use incommunications made in accordance with a second communications protocol;

[0019] derive, from said base address identifier, an amended addressidentifier convertible by a second directory server to an address foruse in communications made in accordance with said first communicationsprotocol;

[0020] wherein at least part of said address identifiers is formed inaccordance with a hierarchical addressing scheme, said part comprising asequence of address identifier components, the position of a componentin said sequence indicating the level of said component in saidhierarchical addressing scheme;

[0021] said method being characterised in that said derivation involvesintroducing amended address components so that a plurality of baseaddress identifiers convertible by said first directory server areconverted to one or more amended address identifiers convertible by saidsecond directory server.

[0022] In this way, it is possible to derive unique address identifiersfor new communications services to be provided over a newly implementedcommunications protocol from respective address identifiers provided forservices associated with a fully implemented communications protocol.The above method provides for a new address space to be created for usewith DNS or other address resolution systems for the provision ofcommunication services associated with a newly available communicationsprotocol. The invention also provides for translation between addressspaces. For instance, if a message is sent but not delivered to a useror location identified by an address identifier generated in accordancewith the above method, the address identifier can be resolved back toits respective original address identifier and the message sent to thelocation associated with that original address by means of a serviceavailable over the first communications protocol. In this respect,address resolution is readily achievable since the respective first andsecond address identifiers are directly derivable from one another. Thisavoids the usual requirement of providing and maintaining of a costlyaddress database for mapping respective first and second addressidentifiers. Another advantage of the above method is that the addressspace is readily scalable. For instance, by using the domain namehierarchy associated with the first communications protocol a new domainname hierarchy can be created and integrated, if appropriate, with DNS.A further advantage of the above method is that users can readilyaddress messages etc, for transmission over one communications protocolusing an address identifier associated with another communicationprotocol. The ability to make use of the address space associated with awidely implemented communications protocol is very important when, say,new services are to be introduced using a new protocol. For example, auser may address a message to another user using a new addressidentifier derived from a known identifier regardless of whether theuser is aware of the recipient's address identifier for the newlyintroduced protocol or whether the recipient has indeed been allocated anew address identifier or is capable of receiving the message over thenew protocol. The user sending the message only requires knowledge ofthe recipient's address identifier associated with the widelyimplemented protocol.

[0023] In contrast to the RFC 2543 proposal of adding an addresscomponent at the lowest level of the domain name hierarchy, the presentinvention provides address components at a higher level than the lowestlevel component in the known e-mail address. The entries in thedirectory can be concentrated in the directory server associated withthe level of the hierarchy that corresponds to the added addresscomponent. Where, as is normally the case, there are a plurality ofinstances of address components below the added address component, thisenables the directory service for the first communications service to beprovided by a single directory server rather than a plurality ofdirectory servers.

[0024] Preferably, at least one of said one or more address componentsis positioned in said sequence such that in said amended addressidentifier, said one or more added address components are associatedwith higher positions in said hierarchy than the address componentsderived from said base address identifier.

[0025] This has the advantage that all directory enquiries can behandled by a directory server under the control of a party introducingsaid first communications service.

[0026] In some embodiments, the base address identifier components areremoved and replaced by amended address identifier components. However,in preferred embodiments, one or more base address components aremaintained in said amended address identifier. This allows addresshierarchies which have evolved in relation to the base addressidentifier to be re-used in the provision of the second communicationsprotocol.

[0027] If all the components of the base address identifier aremaintained in the amended address identifier, then this gives theadvantage that an address (e.g. an e-mail address) which is known to beunique in relation to the second communications protocol is also knownto be unique in relation to the first communications protocol. Inaddition, the base address identifier can be re-created from the amendedaddress identifier, thus allowing the second directory server to revertto the second communications protocol if desired and forward a messageintended to be sent in accordance with the first communications protocolin accordance with the second communications protocol instead. Thisallows, for example, the second directory server, on receiving a SIPmessage for which it is unable to provide an address, to instead send ane-mail to the intended recipient indicated that it has been unable toprovide a SIP connection through to the recipient.

[0028] According to another aspect of the present invention, there isprovided a method of generating address identifiers for use in acommunications network; said method comprising the steps of:

[0029] processing a first address identifier constructed in accordancewith a first communications protocol; and,

[0030] constructing a second address identifier, from said firstidentifier, in accordance with a second communications protocol.

[0031] Preferably, said first identifier is processed in accordance witha pre-determined set of rules to provide said second identifier.

[0032] Conveniently, said first identifier comprises at least oneaddress component and said second identifier comprises at least oneaddress component of said first identifier. In this way addresscomponents can be common to both first and second address identifiers.

[0033] In preferred embodiments, said second identifier includes eachaddress component of said first identifier. This simplifies addresstranslation and allows users to intuitively derive one addressidentifier from the other identifier. This enhances the integration ofservices provided over a newly introduced communications protocol withservices provided over an existing communications protocol.

[0034] Preferably, said step of constructing said second identifiercomprises the step of adding one or more address components to saidfirst identifier. This enhances the above mentioned advantages.

[0035] Conveniently, said method comprises the steps of adding at leastone prefix address component and at least one suffix address componentto said first identifier. This provides for the addition of at least twofurther distinguishing address components.

[0036] In preferred embodiments, said prefix address component isrepresentative of the second communications protocol and said suffixcomponent is representative of a network domain associated with saidsecond network communications protocol. This allows users to identifythe communications protocol that is associated with the newly generatedaddress identifier and the network domain authority for that addressidentifier.

[0037] Preferably, said second communications protocol is an applicationlayer control protocol. This provides for the implementation of userapplications and new communications services over said communicationsprotocol.

[0038] Conveniently, the control protocol conforms to Session InitiationProtocol. Thus SIP messages can be addressed to an existing addressidentifier, for example and e-mail address identifier constructed inaccordance with Simple Mail Transfer Protocol (SMTP), and translated toa corresponding SIP address identifier for transmission to a SIP useragent server regardless of whether the SIP address identifier is knownto the user. Thus, the present invention enables messages to be readilydiverted from a SIP defined destination URL address identifier to acorresponding SMTP defined destination URL address identifier for thesame user or end system. In this way users may send SIP messages to SMTPaddress identifiers using the SMTP network protocol and infrastructureand SMTP messages to SIP address identifiers using the SIP networkprotocol and infrastructure.

[0039] In preferred embodiments, a software program is arranged toimplement the method according to the above-described aspect of theinvention.

[0040] According to another aspect of the invention there is provided asystem for generating address identifiers for use in a communicationsnetwork; said system comprising:

[0041] a processor for processing a first address identifier constructedin accordance with a first communications protocol; and,

[0042] an address identifier constructor for constructing a secondaddress identifier, from said first identifier, in accordance with asecond communications protocol.

[0043] The invention will now be described with reference to theaccompanying drawings in which:

[0044]FIG. 1a is a schematic representation of a typical SIP messagesignalling sequence in a network comprising a SIP re-direct server;

[0045]FIG. 1b is a schematic representation of a typical SIP messagesignalling sequence in a network comprising a SIP proxy server;

[0046]FIG. 2 is a block diagram of a SIP user agent;

[0047]FIG. 3 is a block diagram of a SIP user agent graphical userinterface;

[0048]FIG. 4 is a schematic representation of a communications networkcomprising a plurality of SIP enabled network domains; and,

[0049]FIG. 5 is a flow diagram of a method implemented in thecommunications network of FIG. 4;

[0050] With reference to the drawings, typical signalling sequences areshown in FIGS. 1a and 1 b between two user agents 100 and 102 connectedover a communications network using a SIP redirect server 106 (FIG. 1a),and a SIP proxy server 108 (FIG. 1b). In both arrangements a SIPlocation server 110 is connected to the respective SIP network serverfor address resolution.

[0051] In FIG. 1a, user agent 100 sends a SIP Invite message 112 to useragent 102. The Invite message is received at and processed by there-direct server 106 to determine the network location of user agent102. The re-direct server sends a location query 114 to the locationserver 110. The location server determines the current network locationof user agent 102 and sends this information to the re-direct server ina message 116 for transmission to the user agent 100 in a message 118.User agent 100 then sends an Invite message 120 to user agent 102,either directly or via other SIP re-direct or proxy servers, which thenresponds by sending an acceptance message 122 to the user agent 100.User agent 100 completes the session or call set up procedure by sendingan acknowledgement 124. Once the session has been set up information canbe exchanged between the respective user agents.

[0052] In FIG. 1b, user agent 100 sends a SIP Invite message 126 to useragent 102 as before but instead of being processed by a re-direct serverthe message is processed by the network proxy server 108. The proxyserver sends a location query 128 to the location server 110. Thelocation server determines the current network location of the useragent 102 and sends this information back to the proxy server in amessage 130. The proxy server then relays the Invite message to the useragent 102 by means of a message 132 which is processed by the user agent102. A call acceptance message 134 is then sent back to the proxy serverwhich relays a corresponding message 136 to the user agent 100. The useragent 100 then sends an acknowledgement message 138 to the proxy serverwhich similarly relays a corresponding message 140 to the user agent102.

[0053] With reference now to FIG. 2, a typical SIP user agent 200comprises a front end system in the form of a graphical user interface(GUI) 202, a SIP client program 204, a SIP server program 206, a mediamodule 208, a network interface 210 a SIP address cache 212, a SIP URLaddress generator 214 and a SIP message processor 216.

[0054] A typical SIP GUI is shown in FIG. 3. The GUI 202 comprises aplurality of buttons 302 to 310 each of which represents a different SIPrequest method. Button 302 represents the SIP “INVITE” request forinviting a callee to a SIP session, button 304 represents the “OPTIONS”request for discovering the capabilities of the receiving terminal,button 306 represents the “BYE” request for terminating a call or a callrequest, button 308 represents the “CANCEL” request for terminatingincomplete call requests and button 310 represents the “REGISTER”request method for registering the current location of the user with arespective domain location database 110. The respective request methodsare invoked by a user clicking the respective button, by mousecontrolled cursor click or otherwise. The GUI further comprises a textbox 314 labelled “To: SIP URL” for user input, by keyboard entry oraddress book entry selection for example, of the SIP address identifierof an intended callee, that is to say the SIP destination message headerfield “To”; a text box 316 labelled “To: e-mail URL” for user input ofthe e-mail address identifier of the intended callee; and, a text box318 labelled “Title” for displaying title information to identify thesession. A further text box 320 is provided for the input of other SIPmessage text including for example other SIP header types and textcomprising the SIP message body. Text may be input into any one of thetext boxes 314, 316, 318, 320 using known text processing means, forexample, keyboard entry, selection from pull down menus or cut and pastetext processing applications.

[0055] The SIP message constructor is configured to process data enteredinto any one of the boxes 314, 316, 320, 320 and construct a SIP messageincluding the relevant request type for transmission to an appropriateSIP network server. For example, the message constructor copies the textentered in the text box 314 to the SIP message header type “To:” in theSIP message being constructed. Other header types are determined by themessage constructor such as “Content-type:” and “Content length:” forexample.

[0056] The user agent client program is configured to initiate a SIPsession or “call” and the user agent server program is configured torespond to a call. In this regard the user agent client programimplements the SIP request methods Invite, Options, Bye, Cancel andRegister, and the user agent server implements the methods Invite, Bye,Cancel and Ack methods. Messages are passed from the user agent clientto the network interface 210 for transmission to the intended calleeassociated with the destination SIP URL address. SIP messages arereceived at the destination end by the network interface and areprocessing by the user agent server. The media module 208 provides thenecessary API's for sending system calls to appropriate mediaapplications for processing different media types once a SIP session hasbeen established.

[0057] When a user wishes to initiate a SIP session, the user interactswith the GUI 202 to construct a SIP Invite message including adestination SIP or e-mail address. Once all the necessary data has beeninput to the GUI, including the SIP header types and message body, themessage processor constructs an appropriate SIP message for transmissionto the callee. In the event that the callee's SIP URL address is unknownto the user, the user inputs the callee's SMTP e-mail address in thetext box 316. The e-mail address is then sent to the SIP URL generator214.

[0058] The SIP URL generator 214 comprises a software program forgenerating a SIP URL address identifier from a respective SMTP e-mailaddress identifier for a respective user.

[0059] The SIP URL generator is configured to process the e-mail addressidentifier, in accordance with a set of pre-determined rules, togenerate a corresponding SIP URL address identifier for the callee. Inone arrangement, the e-mail address is processed by the SIP URLgenerator which adds a prefix address component to the existing e-mailaddress components “user@host” etc. The prefix address componentidentifies the communications protocol that the new URL is to be usedwith. In this embodiment “sip” is added as a prefix. A suffix addresscomponent is also added to identify a SIP domain name authority thenewly generated SIP URL address identifier is to be identified with. Inone example the SIP URL generator is configured to process the SMTPe-mail address “alan.oneill@bt.com” to derive the SIP URL addressidentifier “sip:alan.oneill@bt.com.sipit.com”, that is to say, to addthe protocol prefix “sip” and the domain suffix “sipit.com” to theexisting SMTP readable e-mail address “alan.oneill@bt.com”. Thus, theSIP URL generator is configured to generate SIP URL address identifiersby processing a respective address identifier constructed in accordancewith the Internet e-mail communications protocol SMTP. In anotherexample the SIP URL generator is configured to process the same SMTPe-mail address identifier to derive the SIP URL address identifier“sip:alan.oneill@bt.com.uk.sipit.com”, that is to say a geographicalidentifier “uk” is additionally added to the SMTP e-mail addressidentifier. The additional geographic identifier may assist scalabilityof the name space and hence network routing efficiency of the resultingSIP message, for example.

[0060] Referring now to FIG. 4, a plurality of network domains 400, 402and 404 are each connected to the Internet 406 by means of a respectiveSIP network server 408, 410 and 412. In the network of FIG. 4 the SIPnetwork servers are configured for use both as SIP proxy and SIPre-direct servers. The SIP network servers provide access to and fromthe respective domains. Each network domain comprises a plurality of SIPuser agents 200(a-g). SIP user agents 200 a, 200 b and 200 c areconnected to the network server 408 in the domain 400, SIP user agents200 d, and 200 e are connected to the network server 410 in the domain402, and SIP user agents 200 f and 200 g are connected to the networkserver 412 in the domain 404. Each SIP network server is connected to arespective location server 110 for SIP address resolution and anassociated SIP to SMTP e-mail gateway 414. Each SMTP e-mail gateway isconnected to a respective SMTP Mail Transfer Agent (MTA) 416 forrelaying SMTP e-mail messages to respective destination SMTP MTA's overtransport layer TCP connections.

[0061] Each SIP to SMTP e-mail gateway 414 comprises an SMTP e-mailaddress generator 418 and a message processor 420 which comprises anSMTP user agent. The e-mail address generator comprises software forgenerating an SMTP address identifier from a SIP URL address identifier.In this regard the e-mail address generator is configured in a similarbut reverse manner to the address generator 214. The e-mail addressgenerator is configured to process the SIP URL destination addressidentifier of an out going SIP message to derive a corresponding SMTPe-mail address identifier. The e-mail address generator processes theSIP URL address in accordance with the same pre-determined set of rulesas the SIP address generator 214, but processes these rules in reverseorder with respect to the address generator 214. For instance, in oneembodiment a SIP message arriving at the SIP to SMTP e-mail gateway 414is parsed to determine the destination SIP URL. The SIP URL is thenpassed to the SIP to e-mail address generator 418. The remaining part ofthe SIP message is re-formatted by the message processor 420 into SMTPformat suitable for transmission as an SMTP e-mail message.

[0062] In one embodiment the address generator 418 is programmed inaccordance with the above set of rules, that is to say to remove theprotocol identifier prefix “sip” from the SIP URL address and to removethe sip domain suffix component “sipit.com”. The address generator sendsthe re-formatted SMTP address identifier to the message processor wherethe newly derived SMTP address is added to the re-formatted message asthe destination SMTP address for that message. The message processoradds the newly generated SMTP address to the SMTP “To:” header field ofa respective SMTP message. For example, the address generator 418 isprogrammed to derive the SMTP e-mail address identifieralan.oneill@bt.com from SIP URL “sip:alan.oneill@bt.com.sipit.com”.

[0063] The message processor 420 constructs an appropriate SMTP messagefor transmission to the newly generated SMTP address according to thecontent of the respective SIP control message. For example, the SIPmessage payload, for example the SDP message component of the SIPmessage , is added as text to the respective SMTP message body fortransmission to the respective destination SMTP address. In the exampledescribed with reference to FIG. 3, the SDP text shown in box 320 isprocessed and added as text to the SMPT message payload by the messageprocessor 420.

[0064] With reference now to the flow diagram of FIG. 5, a userinitiates a SIP session in step 500 by interaction with the GUI 202 of aSIP user agent 200. A data entry for each of the required data types isinput by the user including a destination SIP address in box 314 or, inthe absence of a known SIP URL for the intended recipient, an SMTPe-mail address that is known to be allocated to the recipient in box316. Data relating to the SIP message is processed into SIP format bythe SIP message processor 216 and is then submitted to the user agentclient 204 by the user selecting the Invite button 302 by mouse click orother data input command. The user agent client determines in step 502whether a SIP URL address has been provided or an SMTP e-mail address.If a SIP URL has been provided processing proceeds to step 508. However,if an SMTP e-mail address identifier has been provided the user agentclient sends the e-mail address to the address generator 214 forprocessing to a respective SIP URL address identifier in step 504. Arespective SIP URL is generated in accordance with the above describedmethod. In step 506 the newly derived SIP URL address is added to theSIP destination header type “To:” following the INVITE request type ofthe SIP message.

[0065] The SIP message is transmitted to the appropriate local SIPnetwork server 408, 410 or 412 in step 508 to be relayed or re-directedto a network server associated with the destination SIP URL address. Thenetwork server that receives the SIP message queries its associatedlocation database 110 in step 510, using DNS or other address resolutionmeans, to determine the network server the SIP message should betransmitted to. In step 512 a network server having authority for thedomain for the destination SIP URL determines whether the destinationSIP URL address is a valid network address, that is to say, whether theSIP URL address has been allocated by the domain authority to a SIPuser. The SIP URL destination address is a valid network address if itcan be resolved by a location database using DNS or other resolutionmeans to a respective numerical IP address, for example. In this respectaddress resolution may involve querying other location databasesassociated with other network SIP servers or SIP domains in a similarway that DNS resolves numerical IP addresses. In step 514, if thedestination SIP URL address is valid, that is to say it has beenallocated to a respective user and can be resolved, the location serverreturns the IP address of the next SIP server that is configured torelay or re-direct the message or if appropriate the IP address of theend system currently associated with the destination SIP URL. The SIPmessage is sent to the next SIP network server or destination end systemin step 516. If the SIP URL is invalid, that is to say it has not beenallocated by the appropriate domain authority for use in the network, anappropriate SIP network server transmits the SIP message to anassociated SIP to SMTP e-mail gateway in step 516. The destination SIPURL may be invalid for instance because it was automatically generatedfrom a known e-mail address identifier in step 504 and no correspondingSIP address exists. Under these circumstances the message processor 420re-formats the SIP message to an SMTP message for communication over theInternet 406 in accordance with SMTP in step 518. In step 520 thedestination SIP URL address is processed by the address generator 418 instep 520 to derive the SMTP e-mail address encapsulated within the SIPURL address. Additional information and data is added to there-formatted SMTP e-mail message in step 522 including, for example thetext:

[0066] “You were called by SIP user <sender's SIP URL and associateddata> at <time, date> with message <SIP message body content (SDP)> butyou were not found in the SIP registration system. You can register at<http hyperlink> where you can download a SIP client.”

[0067] or,

[0068] “You were called by SIP user <sender's SIP URL and associateddata> at <time, date> with message <SIP message body content (SDP)> butyou were not found in the SIP registration system. You can registerusing the attached http form <http registration form with mailto: URIaddress>. A SIP client <SIP client executable code> is attached.”

[0069] The SMTP message is sent to an associated mail transfer agent 416in step 524 for transmission to the e-mail address derived in step 520using the SMTP network protocol. In step 526 the sender is informed bythe SIP server that the destination SIP URL was not valid and that themessage was instead re-formatted according to SMTP and sent to the SMTPe-mail address derived in step 520.

[0070] It will be seen that the other embodiments of the presentinvention could be readily implemented by the skilled person, forinstance instead of the SIP message being diverted to a SIP to e-mailgateway in the event that the destination SIP URL address is invalid, aSIP message could be readily diverted to a SIP to e-mail gateway if theuser or the end system associated with the user was unavailable orunwilling to receive SIP messages at the time of message transmission.In one embodiment, the respective SIP server selects an appropriatemessage from an associated message library (not shown) for inclusionwith the original SIP message in step 522. The message library includesa respective delivery failure message for each SIP message deliveryfailure mode, including for example, destination SIP user agentunavailable, user unavailable, network connection failure, userunwilling to join SIP session or user unwilling to join designatedsessions, user will be available at <time, date>, etc.

[0071] It will also be seen that in other embodiments the SIP to e-mailgateway 414 could be readily implemented in other network devices suchas a respective network SIP server or a SIP user agent.

1. A method of operating a network to provide communications inaccordance with a first communications protocol, said method comprising:receiving a base address identifier convertible by a first directoryserver associated with said network to an address for use incommunications made in accordance with a second communications protocol;derive, from said base address identifier, an amended address identifierconvertible by a second directory server to an address for use incommunications made in accordance with said first communicationsprotocol; wherein at least part of said address identifiers is formed inaccordance with a hierarchical addressing scheme, said part comprising asequence of address identifier components, the position of a componentin said sequence indicating the level of said component in saidhierarchical addressing scheme; said method being characterised in thatsaid derivation involves providing amended address components so that aplurality of base address identifiers convertible by said firstdirectory server are converted to one or more amended addressidentifiers convertible by said second directory server.
 2. A methodaccording to claim 1 wherein at least one of said one or more addresscomponents is positioned in said sequence such that in said amendedaddress identifier, said one or more added address components areassociated with higher positions in said hierarchy than the addresscomponents derived from said base address identifier.
 3. A methodaccording to claim 1 in which one or more of said base addressidentifier components are maintained in said amended address identifier..
 4. A method according to claim 3 in which all of said base addressidentifier components are maintained in said amended address identifier.